persist: audit and cut per-shard metric cardinality - #38664

Six per-shard families were only ever read summed over all shards, so
the shard label bought nothing but one series per shard per process.

The three `mz_persist_backpressure_*` families keep their names and lose
their labels. They are set by the persist_source backpressure operator,
which never runs in environmentd, so there every one of those series was
a zero. The gauge among them now reads as the sum over live operator
instances, each contributing its most recent value through
`GaugeContribution` and withdrawing it on drop.

The operator's metric bundle, `BackpressureOperatorMetrics`, is shared
with the upsert operator. It now holds plain handles, and each owner
keeps its own series alive: the persist client through its process-level
`BackpressureMetrics`, upsert through the new per-worker
`UpsertBackpressureMetrics`.

The three `mz_persist_shard_pubsub_diff_*` counters move next to the
other pubsub receiver metrics as
`mz_persist_pubsub_client_receiver_diff_{applied,not_applied_stale,not_applied_out_of_order}`.

`mz_persist_shard_since`, `mz_persist_shard_upper`,
`mz_persist_shard_stale_version`,
`mz_persist_shard_schema_registry_version_count`,
`mz_persist_shard_inline_part_bytes` and
`mz_persist_shard_batch_part_version_bytes` appear on no curated
dashboard, only on the everything dump. Frontiers per collection are in
`mz_internal.mz_frontiers`, `mz_persist_shard_count` already counts
shards, and each of the two `_bytes` families has a `_count` sibling on
the shard dashboard.

The release sign-off reference counted `mz_persist_shard_upper` series
to get a shard count and now points at `mz_persist_shard_count`.

The audit dropped the per-shard `mz_persist_shard_stale_version` 0/1
gauge along with the other per-shard families. Its signal has real
coarse value though: it is the rollout / mixed-version progress signal,
telling us how many shards a process still holds at a state version
behind its own build.

Fold it to a process-level `mz_persist_stale_shard_count`: the sum of the
old per-shard flag, O(1) series per process instead of one per shard.
`ShardMetrics` carries a plain `stale: AtomicBool` (not a registered
series) that the CaS apply path sets.

Both process-level shard aggregates (this and the existing
`mz_persist_shard_count`) are sums over the shards map, so a
`register_computed_gauge` closure apiece would lock and walk the map once
per gauge per scrape. Collect them in one pass instead: a
`ShardsAggregateMetrics` collector shares the `shards` map and folds both
totals in a single walk.

Also document `LockingTypedState.shard_metrics`, now retained only to
keep the shard's series registered while the state is cached.